Date: Thu, 13 Jan 94 04:30:02 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #9 To: tcp-group-digest TCP-Group Digest Thu, 13 Jan 94 Volume 94 : Issue 9 Today's Topics: a blast from the past DOS-OS/2 TCP/IP KISS and SLIP Packet Drivers TNC3? (2 msgs) Usenix Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Wed, 12 Jan 1994 19:59:24 -0800 From: brian@nothing.ucsd.edu (Brian Kantor) Subject: a blast from the past To: tcp-group@ucsd.edu I just found a note I wrote back in 1988: My view of the AMPRNET In my vision of the AMPRNET, the network consists of a moderate number of specialized network nodes dedicated to the network itself that provide forwarding, routing, and access to the network. Each of these nodes is conceptually similar, and characterized by: 1. High-speed links to its neighboring nodes. Right now 56kb on 900MHz and/or 1200MHz is the method of choice; in future other bands and rates will become preferred. 2. Duplex operation. Each node will have an exclusive transmit frequency in its area, and will listen for its neighbors on their respective frequencies. Thus the typical node will have more receivers than transmitters, with a node having N neighbors having N receivers. NB: if it is anticipated that two neighbors to a high-density node will each have low enough traffic to should share a frequency, that can be done, but there is a problem with hidden-station frequency contention to be solved. This can be done by using a low-bandwidth channel as a busy signal - a transmission on the busy channel indicates that the high-density node is hearing signals on the corresponding high-speed data channel. A node with more than one input that is to be shared would use different tones on the busy channel to indicate which of its input channels is in use. 3. Connectivity to each neighboring node is maintained by using a permanent virtual circuit from the node to each of its neighbors. (For now, these will be AX.25 connected-mode streams. Later, when we have a better legal protocol, we'll use it.) These PVCs will use a keepalive message to periodically test connectivity and to ensure a minimum channel presence. The keepalive will have the benefit of ensuring proper station identification on an otherwise idle link as well. A link which times out is marked as down, disconnected, and connection is periodically retried. 4. Adjacency information is exchanged by nodes listing each of their operational neighboring node connections and an indication of the current or averaged outgoing queue length. This data is periodically multi-cast to each of a node's operational neighbors. The protocol to be used for exchanging this information is not yet defined. 5. Routing is done by compiling a list of each node's link adjacency information and associating this with a list of the subnets for which that node is a gateway. A network-wide table of routes can be built by flooding this information among the nodes of the network, probably at some infrequent periodic interval or perhaps in response to an event such as a node outage. Restrictions need to be placed on the frequency of such updates to ensure that the networks bandwith is not consumed by such messages. NB: it is not necessary for a list of all reachable IP addresses to be propagated throughout the network, but only a list of subnets and the nodes which can gateway to them. The algorithms for calculating this routing are not perfected and should be the subject of considerable experimentation. 6. Multiple subnet gateways are possible, and often desireable. When such exist, it will be desireable for each of the gateways for a subnet to exchange host reachability information, which can be used to determine which of a set of gateways to a subnet is preferred for traffic to a specific host on that subnet. This information can be obtained from static tables, connection history, or wiretapping algorithms, and is used to issue ICMP Redirect-for-Host messages, or to calculate second-best-route information. The protocol for exchanging this information is as yet undefined. 7. User access to the network is made available by additional ports on the network node. A popular node in an area with avid experimenters might need several of these: perhaps 1200bps on 145MHz, 9600bps on 222MHz, and 56kbps on 433MHz. User stations will not normally participate in the node-to-node links and should stay off those channels. Both vanilla-AX.25 connected terminal mode (i.e., a telnet server) and IP forwarding should be available to users so that the network can be used by both basic and advanced packeteers. NB: the PS-186 network processor was designed with 4 high-speed ports [and capability of expansion to more] for precisely this sort of application. 8. Services such as message drops and ftp warehouses should not be provided by the network nodes. Instead, they should be similar to user stations and access the node on one of its access ports. It would be possible to use coupled processors, perhaps connected by non-radio means such as an SCSI port, in those areas where the network node and the service host can be installed together, but the key is to not burden the network processor with non-network tasks. 9. Diverse connection types should be possible. Satellite paths, wormholes, high-speed non-radio (optical?) links, perhaps even gateways to other types of networks [eg, the W0RLI BBSs] may be desireable. Some of these are more advanced applications than a simple packet switch may wish to provide [eg, a telnet-to-AX.25-stream server to allow connection in keyboard mode from the network to a vanilla user TNC], but other node implementors may consider them to be an essential part of the network and thus will provide them. Again, the protocols and facilities for many of these kinds of services have yet to be designed. 10. Political considerations should be taken into account in the development, construction, operation, and placement of nodes. It might be desireable that a node be sponsored by a packet radio club or other organization to ensure that nodes don't come and go with the vagaries of personal whim, but conversely, they should not be bound by some feelings of "we have to provide something the paying users can see NOW." This is a narrow ledge to tred, but it is clear that this network is now and will remain for some time an EXPERIMENTAL project, not a common carrier. We should feel unrestrained in trying new protocols, algorithms, hardware, and concepts in our network. In other words, we should not be afraid to break the network occasionally. After all, we're trying to advance the state of the art here, not replace the telephone network. As an ESSENTIAL part of this effort, people experimenting with this network should make their experiments, results, and probably their software available to other experimenters. It is thus incumbent upon experimenters to PUBLISH THEIR WORK. NB: Phil Karn's 'NET' package is an excellent example of how to do this. It is copyrighted, available at no charge to the ham radio community, yet he does license it and collect some money for commercial uses. Thus the hams get to play for free, and he isn't deprived of remuneration for his endless hours of effort. Everybody wins. ------------------------------ Date: Tue, 11 Jan 1994 18:59:28 -0500 (EST) From: Mike Bilow Subject: DOS-OS/2 TCP/IP To: crompton@NADC.NADC.NAVY.MIL IBM posted the details of their special offer for TCP/IP v2.0 for OS/2 2.x at their software.watson.ibm.com machine. I think the file was tcpip20.ann, but I don't remember it in detail and I certainly could not point anyone to a directory. The OS/2 Special Edition, commonly known as "OS/2 2.1 for Windows" is widely available on retail shelves. The local Egghead and CompUSA have had it for some time, since about mid-November. The price is $49 for the floppy disk version and $39 for the CD-ROM version, but this is a special that is scheduled to end on Feb. 4. There is a FAQ file I have seen, probably on ftp-os2.cdrom.com, os24wfaq.zip, which answers the common questions about the "OS/2 for Windows" product. Basically, it is a full version of OS/2 that assumes you already have Windows 3.1 installed. The price is lower, since IBM does not have to pay the royalties associated with the WIN-OS/2 component of regular OS/2 to Microsoft, and the amount of disk space required is reduced by the 10 MB or so that WIN-OS/2 uses. The functionality of OS/2 for Windows when installed after Windows 3.1 should be the same as that of regular OS/2. (The only technical difference that I know about is that the Win32s patches can be installed after OS/2 for Windows, but not at all with regular OS/2.) -- Mike ------------------------------ Date: Wed, 12 Jan 94 17:16:14 GMT From: Jan Schiefer Subject: KISS and SLIP To: TCP-Group@UCSD.EDU Phil writes: > [..] > As time goes on, I become even more firmly convinced that "smart" > controllers are a dumb idea. Controllers should be simple, fast and > easy to program. The host computer should do the rest of the work. > [..] > purpose host computer CPUs and memory. And for every host cycle that > you save offloading some protocol function, you end up spending it on > some new complex host-to-front-end protocol that you didn't need > before. Agreed. So if you *have* to have a frontend you want as much as possible of the host-frontend communication protocol done in hardware. Ethernet is an example for this, with the powerful chipsets available. Another option might be to use IEEE488 (or HPIB, GPIB, IEC625, whatever you prefer). No, don't say 'b...s...' to quickly, read on. It is easy to implement, has quite a good performance, no flow control problems because of the acknowledge lines, you can put up to 15 devices to a single interface and you have some protocols for arbitration (like parallel and serial poll). To test this idea I have built a simple add-on interface for a TNC2 which consists of 5 chips (a GAL, a latch, a NEC TLC7210 IEC-bus controller and two line drivers) and a DIP-switch for the bus address. The interface is attached to the TNC by piggybacking the SIO and adding two more cables. The test software works, but unfortunately I haven't had the time to adapt some packet software to it yet, so I am still lacking real-life performance figures. With IEEE488 one is not restricted to host-frontend comms. You can have controller-controller as well. I'd be happy to hear any comments about this approach. Ah yes, and the PC interface is just as trivial and cheap as the TNC one. 73, Jan, g0trr//dl5ue -- Jan Schiefer, g0trr, jas@hplb.hpl.hp.com, HP Labs Bristol, UK. +44 272 228344 Finally, I discovered a way to create lines longer then 80 columns, even on term ------------------------------ Date: Wed, 12 Jan 94 14:35:45 EST From: waltp@bingsuns.cc.binghamton.edu (waltp) Subject: Packet Drivers To: TCP-Group@UCSD.edu Does anyone know where I can get packet drivers for a 3com 3c523b (microchannel ethernet board) and / or IBM's microchannel token ring board? Thanks Walt -- --- Walter G. Piotrowski waltp@bingsuns.cc.binghamton.edu --- Computer Science Department - Binghamton University --- Binghamton, NY 13902-6000 (607) 777-4368 --- Ham Packet: wb1ere@wf2a.ny.usa.na Ham TCP/IP: 44.69.0.41 ------------------------------ Date: Wed, 12 Jan 1994 09:48:56 -0500 From: Gary Skuse Subject: TNC3? To: tcp-group@ucsd.edu Can anyone shed some light on the rumors we've heard about a TNC3? There is some obvious room for improvement on the TNC2 design and I am curious about whether anything has been done. I guess the most important question, is whether a TNC3 currently exists or whether is is "planned"? Thanks for any light you can provide. 73, ka1njl ------------------------------ Date: Wed, 12 Jan 1994 08:55:50 -0800 From: brian@nothing.ucsd.edu (Brian Kantor) Subject: TNC3? To: tcp-group@ucsd.edu I saw a breadboard (wirewrapped?) version of the TNC-3 at a TAPR meeting a year or two ago. At the time, it seemed to me to be an underwhelming achievement, as it really didn't do more than update the TNC to a newer bigger faster processor, and I think it added a second port. In other words, it looked like a Kantronics data engine to me. Perhaps I missed something. By the way, I get the feeling that TAPR has lost its edge. It seems it's more of a social club than a technical innovation group these days, although Lyle is still coming up with new things. I suspect he'd do that even if TAPR folded. - Brian ------------------------------ Date: Wed, 12 Jan 1994 21:03:30 -0800 From: brian@nothing.ucsd.edu (Brian Kantor) Subject: Usenix To: ham-bsd@ucsd.edu, tcp-group@ucsd.edu If any of you will be attending the Usenix conference in San Francisco next week, we may want to get together and have lunch or drinks or something. I'll put a note on the message board or something if there's any interest. - Brian ------------------------------ End of TCP-Group Digest V94 #9 ******************************